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This is in response to the appeal brief filed 04/03/2008 appealing from the Office action 
mailed 08/03/2007. 
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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial 
proceedings which will directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection 
contained in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

6,327,628 Anuffetal. 12-2001 
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(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claims 1-25 are rejected under 35 U.S.C. 102(b) as being anticipated by 
Anuff et al. (US 6,327,628) hereinafter Anuff. 

For claims 1 -5, 7-1 0, 1 2-1 5, 1 7-20 and 22-25, Anuff teaches a computer 
implemented system and corresponding method comprising: 

determining a construction design for an adapted portal application wherein said 
determining a construction design includes one or more of: 

determining a visual theme of said adapted portal application (determining 
a visual theme means determining the look and feel of the portal 
application, column 2 lines 13-16, also subsection 8-8.6); and 
determining a format of content for said adapted portal application 
(content is formatted in a predetermined layout, Abstract and column 2 
lines 1-3, also subsection "3.4 page layout"); 
determining a model for separation or presentation logic and application logic of 
an existing Web application to be adapted into said portal application (Anuff teaches 
that the views are the means by which the portal server isolates the presentation logic 
from the application logic, subsection 3.3.2); 
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determining a navigation construction for said adapted portal application wherein 
said determining a navigation construction includes: 

retrieving selected information based on an event defined by uniform 
resource locator (URL) interaction in said Web application (Fig. 2 shows 
various URLs that are usable to retrieve selected information based on an 
event such as clicking a URL, also link 22 as mentioned in column 3 lines 
52-54); 

selecting a level of customization to apply to said adapted portal application 
wherein said selecting a level of customization comprises one or more of: 

presenting an interactive window to obtain customization information from 
a user (buttons or links 24 in Fig. 2 are used to launch an interactive 
window that allow the user to personalize the portal, column 3 lines 52- 
57), wherein said obtained customization information is stored in a portal 
framework (LDAP directory or SQL database shown in Fig. 3, column 9 
lines 30-34, also column 13 lines 25-30); and 

retrieving existing login information related to said user for inclusion in 
content of said adapted portal application (column 9 lines 30-34, also 
column 13 lines 25-30); 
selecting an isolation model for isolating business logic from said adapted portal 
application wherein said selecting an isolation model comprises one or more of: 
modifying said business model to return output as at least one data- 
descriptive meta language document (column 10 lines 52-62); and 
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creating a component to connect said adapted portal application to one or 
more Web services for providing said business logic to said adapted portal 
application (the server part of the portal server shown in Fig. 3, column 4 
lines 16-33); and 

employing the determined construction design, the determined model, the 
determined navigation construction, the selected level of customization, and the 
selected isolation model for adapting said existing Web application into said 
portal application in a manner that maintains said existing Web application's 
functionality within said portal application (implied in the reference since such 
employment is necessary in order to realize the disclosed portal infrastructure 
that is intended to maintain the existing Web application's functionality within the 
modular portal infrastructure but in a streamlined and cost effective manner 
(d:40:62). 



For claims 6, 1 1 and 21 , Anuff teaches adapting a web application to a portal 
application comprising: 

adding at least one component of said Web application to a portal platform (Fig. 
2 shows various components of a web application such as Search, Company Directory, 
News and Discussion Boards that are added to a portal platform); 

creating a plurality of portlets within said portal platform, wherein each of said 
plurality includes pages representing a view for said at least one component of said 
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Web application (each module displayed on the portal front page as shown in Fig. 2 is a 
portlet that contains pages representing a view for a particular network resource); 

defining at least one Web flow relationship representing interactions between 
said at least one component of said Web application (defining at least one Web flow 
relationship is inherent in the reference since there has to be a defined Web flow 
relationship in order to show the appropriate page based on the user interaction at the 
portal, Fig. 2); and 

converting said at least one Web flow relationship into at least one event, defined 
within said plurality of portlets, wherein said at least one event corresponds to said 
interactions (Anuff teaches implementing the defined Web flow relationship by 
converting it into user selection events such as selecting a link or button in order to 
display appropriate page based on the selection, Fig. 2). 

For claim 16, Anuff further teaches displaying a second user interface to a user 
for updating the personal login information ("Edit Account" link in Fig. 2). 

(10) Response to Argument 

Beginning on page 1 1 of Appellant's brief (hereinafter Brief), Appellant argues 
specific issues, which are accordingly addressed below. Appellant has elected to group 
the following claims together and only present arguments for claims 1 , 3, 6, 1 1 , 1 9, 21 , 
and 24. Therefore, the Examiner will present arguments based on the elected 
groupings. 
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Page 7 



Independent Claim 1 and Dependent Claims 2 and 4-5 

Regarding Claim 1 , Appellant mentions, "Anuff fails to teach all elements of claim 1." 
However, in particular, Appellant argues, "While Anuff proposes a modular portal 
infrastructure or framework, Anuff fails to address any technique for adapting an existing Web 
application into the proposed portal infrastructure." 

In response to the above arguments, the Final Office Action explained the 
rationale for the rejection based on an interpretation of the recited "existing Web 
application". The explanation for the rejection provided in the Final Office Action is 
provided below for the convenience of the reader. 

"For claim 1, Applicant argues, 'while Anuff proposes a modular portal infrastructure or 
framework, Anuff fails to address any technique for adapting an existing Web application into 
the proposed portal infrastructure' (Applicant's Remarks: pi 5: 21-23). The Examiner disagrees. 
It appears that the Applicant relies on the fact that Anuff does not disclose adapting an instance 
of an implementation of a Web application into a portal infrastructure. The Examiner realizes 
that Anuff does not explicitly teach a technique that takes coded components, in other words an 
instance of an implementation, of a Web application and modify or incorporate those coded 
components to form corresponding modules to be used in its portal framework, although such 
modification would have been obvious based on his teachings. But such limitation is not required 
by the claim as it is drafted at present. A "Web application" as recited in the claim, can 
reasonably be interpreted, in the broadest reasonable interpretation, to mean a concept of a Web 
application. For example, just the concept of searching the web with a keyword for retrieving 
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information relevant to the keyword can be broadly referred to as a Web application, even 
though this concept can be implemented using various different techniques as various different 
instances of implementation of the Web application. Therefore, "an existing Web application" as 
recited in the claim can reasonably be interpreted to mean "a known concept of a Web 
application" and not necessarily be interpreted to be an existing instance of a particular 
implementation of a Web application. Interpreted as such, claim 1 only requires a method for 
adapting a known concept of a Web application into a portal infrastructure using the steps 
recited. Note that the claim does not need that an existing instance of an implementation be 
present and modified or incorporated or adapted into the portal infrastructure. In other words, the 
portal infrastructure can be implemented from scratch if needed. Therefore, 'an existing Web 
application to be adapted into said portal application'' only requires use of a known concept of a 
Web application and to make it suitable to or fit for a specific use or situation (American 
Heritage Dictionary defines the word "adapt" as "To make suitable to or fit for a specific use or 
situation") by implementing the concept as a portal framework. Such a portal framework is thus 
an 'adapted portal application ' as recited in claim 1 . Anuff teaches a modular portal 
infrastructure that uses the existing concepts of browser applications (e.g., Web applications such 
as web search, company directory search, News etc. as shown in Fig. 2) and adapts those 
application concepts to meet the desire of today's corporate users 'to have quick access to 
various resources and data provided by the employer, while at the same time being able to view 
information provided over the internet, such as news headlines, financial data, and vendor data' 
(c3:36-39) at once from a single site using a portal infrastructure. Anuff further realizes that the 
use of a portal infrastructure to adapt existing Web application concepts into a one-site gateway 
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to the Web was not a new concept or technique. He teaches that by the time of his invention 
'portals have become popular mechanisms that enable users to access information from multiple 
different network sites at once' (c3:37-39). Therefore, even the concept of a portal infrastructure 
itself can be thought of as "an existing Web application" at the time of the invention. Therefore, 
it can be said that Anuff further teaches a technique for adapting an existing portal Web 
application into a modular portal infrastructure to make it suitable to or fit for the current 
organizational need for streamlining the processes involved in offering a feature-rich portal while 
minimizing the complexity and cost of developing, deploying, administering and continually 
enhancing portals (c 1:40-62). Therefore, Anuff clearly anticipates the claim as pointed out in this 
Office Action above." See Final Office Action, pages 7-8. 

In reply to the above argument from the Examiner, Appellant argues in the 
Brief, "Examiner's interpretation of an "existing Web application ' as a known concept of a Web 
application (which appears to refer to a known functionality that is performed via the Web, such 
as the concept of performing keyword searching over the Web) is unreasonably broad. The claim 
language should be interpreted consistent with the specification of the application. That is, the 
claims are to be given their broadest reasonable interpretation in light of the specification, see 
M.P.E.P. §2111. "Claims are not to be read in a vacuum, and limitations therein are to be 
interpreted in light of the specification in giving them their 'broadest reasonable interpretation' ." 
M.P.E.P. § 2111.0 1 (II), quoting In re Marosi, 710 F.2d 799, 218 USPQ 289 (Fed. Cir. 1983). 
Indeed, if read in a vacuum, the word "Web" could be interpreted as a spider web, rather than the 
well-known computer network referred to as the "Web". Likewise, when properly interpreted in 
light of its usage in the specification of the present application, "an existing Web application" is 
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not reasonably interpreted as referring to any known function (or concept) that can be performed 
via the Web." Applicant further cited portions of the instant specification asserting that the 
limitation "existing Web application" when afforded a reasonable interpretation 
consistent with its use in the specification of the present application is an instance of an 
implementation of a Web application, rather than a concept of a Web application and 
asserts that Anuff fails to teach this limitation of claim 1 as conceded by the Examiner in 
the Final Office Action. See Brief, page 14. 

In response to applicant's argument the Examiner notes that MPEP 21 1 1 .01 (II) 
states that the claims are interpreted by the Office (PTO) based on their plain meaning 
unless such a meaning is inconsistent with the specification. Further, MPEP 21 1 1 .01 
(III) states that the plain meaning refers to the ordinary and customary meaning given to 
the term by those of ordinary skill in the art in question at the time of the invention. 
Based on the above guidance, the Examiner considers the ordinary and customary 
meaning given to the term "existing Web application" by those of ordinary skill in the art 
in question at the time of the invention would have been "a known concept of a Web 
application" when considered broadly and such interpretation is not inconsistent with the 
disclosure provided in the instant specification, and thus not unreasonable. Therefore 
the Examiner believes the rejection to be proper. 

However, upon further consideration of the reference in question for the 
preparation of this Answer, the Examiner believes that Anuff in fact teaches adapting an 
existing Web application into a proposed portal infrastructure even if the terminology "an 
existing Web application" is interpreted to mean not just a known Web application (i.e., 
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in the form of a concept or knowledge) but an actual instance of a particular 
implementation of a Web application (i.e., a Web application constructed from a number 
of Web components appropriately coded by the developer that provide some 
information or application logic to the user). This is because Anuff teaches that each 
module within the portal represents a network resource (i.e., a Web application) that can 
be accessed by a user through the portal (see Abstract). He further mentions, "As will be 
apparent from the discussion that follows, these resources can be applications, databases, 
services informational content, e-commerce offerings, and the like, that are available from one or 
more of the servers 12a-12n. Some of these resources may be provided by the employer (or other 
provider of the portal), whereas others may come from independent third parties ." Emphasis 
added, see c3:61 -c4:1 . Elsewhere he again mentions, "One of the significant advantages of 
the portal framework of the present invention is the fact that the resources that are made 
available to the user via the modules can come from a variety of third-party sources . Emphasis 
added, see c1 0:52-55. Since some of the modules on the portal platform make available 
to the user resources provided by third parties, it follows that these third party resources 
represent existing Web applications, since at least these third party resources are not 
built from scratch by the portal provider but represents resources that are already 
provided by third parties. Therefore, by providing access to these third party Web 
application resources via designing and implementing the modular portal, Anuff teaches 
a technique for adapting an existing Web application into the proposed portal 
infrastructure. The notion that Anuff teaches a technique for adapting an existing Web 
application to the portal platform is further supported by the teaching that the portal is 
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said to be an object-oriented system built on an object model, illustrated in Figs. 4, 6 
and 7, using objects built on top of existing objects. Regarding the object model built 
using object oriented paradigm, Anuff mentions, "Software objects are also extensible: other 
objects can be built on top of existing objects , allowing the new object to extend the concept of 
the old object without having to rewrite the functionality ". Emphasis added, see c4:54-57. 
That is, Anuff at least implicitly teaches that the modular portal is built using new module 
objects which extend the concept of old module objects without having to rewrite the 
functionality. Additionally, Anuff elsewhere teaches utilizing technology for allowing 
configuration-data driven resolution of service implementations within the portal server, 
and mentions, "This allows the portal provider to use existing implementations or define their 
own, and substitute their chosen implementation into the system without rewriting source code 
that uses the implementation ." Emphasis added, see c5:49-67. It is because Anuff 
incorporates components of existing Web applications into his portal platform for 
adapting an existing Web application into the proposed portal infrastructure, that "an 
entire working portal can be up and running very quickly: in hours or days, rather than weeks or 
months that were required prior to the invention. Organizations can, at their own pace, change all 
aspects of the look-and-feel of the portal, integrate their own content, and use the portal server's 
development tools to extend out-of-the-box functionality. ..thereby promoting integration with 
existing systems and reducing required learning time." See d 7:27-37. Referring to Fig. 2 
again, none of the modules 26 such as "Bookmarks", "Search", "Company Directory", 
"News", and "Discussion Boards" represent any novel Web service functionality but are 
known functionalities in the art at the time of the invention. It would be unreasonable to 
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believe that a person of ordinary skill in the art would rewrite the code for these modules 
from scratch. In the contrary, a skilled artisan would readily realize that one is more 
likely to re-use existing codes for developing at least some portions of these modules as 
part of the modular portal platform. Therefore, the Examiner believes that Anuff teaches 
a technique for adapting and existing Web application into the proposed portal 
infrastructure whether the terminology "an existing Web application" is interpreted as 
mere concept or not. 

For claims 2 and 4-5, the Appellant has not provided any additional argument 
besides what has been already discussed above with respect to claim 1 . Therefore, the 
same argument applies for these claims. 

Dependent Claim 3 

Dependent claim 3 depends from claim 1 . Therefore, the same argument as 
discussed with respect to claim 1 above also applies to this claim. Appellant further 
argues, "Anuff further fails to teach creating a new window for information retrieved in 
response to a call to a URL from a Web application". See page 1 5 in the Brief. The 
Examiner disagrees. Referring to Fig. 2, Anuff shows portlets, i.e., modules 26, with 
titles "Bookmarks", "Search", "Company Directory", "News" and "Discussion Boards". 
Each of these modules either alone or in combination has been relied upon as "said 
Web application" recited in the claim (see the discussion with respect to claim 1 above). 
The illustration of Fig. 2 shows a "Portal Front Page" 18 (see c3:44-45). This "Portal 
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Front Page" is also illustrated in the object model of Fig. 4. As shown, a module window 
corresponds to a "View" object in the object model of Fig. 4. Now referring to section 
3.3.2 Views, Anuff teaches, "Examples of views are the front page of a portal, where a module 
is displayed within a box or other graphical region (as shown in Fig. 2);" (see c6:51 -54). He 
further mentions, "A new view object is created for each HTTP request." (see c6:57-58). 
From the above description, it is apparent that a "View" object corresponds to a 
"window" containing the module 26 of the Portal Front Page as illustrated in Fig. 2. Also, 
it is implicit in the reference that the news headlines displayed in the News module in 
Fig. 2 are URLs. Now based on the teaching that by interacting with any one of these 
modules, the user can access the information or services provided by that module, and 
by clicking on a headline in the "News" module, the user can be presented with the full 
text of the news story to which that headline pertains (see c4:1-5), it is apparent that 
Anuff teaches retrieving information in response to a call to a URL from a Web 
application. Furthermore, since it is well known that a URL call generates an HTTP 
request (also shown as HTTP Connection in Fig. 12), and the explicit teaching "a new 
view (i.e., a window) object is created for each HTTP request" (see c6:57-58), it follows 
that Anuff teaches "creating a new window for information retrieved in response to a call to a 
URL from a Web application". 

Independent Claim 6 and Dependent Claims 7-10 

Regarding claim 6, Appellant mentions, "Anuff fails to teach all elements of claim 6". 
In particular, Appellant argues, "While Anuff proposes a modular portal infrastructure or 
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framework, Anuff fails to address any technique for adapting an existing Web application into 
the proposed portal infrastructure. Thus, Anuff fails to disclose a method for 'adapting a Web 
application to a portal application' in the manner recited by claim 6." This appears to be the 
same argument that Appellant has argued for claim 1 . Therefore, the Examiner 
disagrees for the same reasoning as explained above with respect to claim 1 . For the 
sake of brevity, the same argument discussed with respect to claim 1 is not repeated 
here. However, the Examiner would like to point out that claim 6 does not even recite 
the limitation "existing Web application" which was recited in claim 1, but only recites "a 
Web application". Appellant argues, "Indeed , claim 6 expressly recites that the Web 
application has at least one component, and a Web flow relationship is defined representing 
interactions between said at least one component of said Web application... Accordingly, 
interpretation such an existing Web application as a known concept (or function) of the web is 
particularly unreasonably broad with regard to claim 6, which expressly recites that the Web 
application comprises at least one component." See page 17 in the Brief. The Examiner 
disagrees. The limitation "at least one component of said Web application " does not 
necessarily require that the component is a coded component. Therefore, the limitation 
"adding at least one component of said Web application to a portal platform" can reasonably 
be interpreted to require that the functionality of at least one component of a known 
Web application is provided via a portal platform, even if the Web application is not 
implemented with components appropriately coded by developers, but exists merely in 
conceptual form as prior art knowledge of a skilled artisan. Anuff clearly teaches this. As 
already mentioned above in the response to the argument with respect to claim 1 , Anuff 
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realizes that the use of a portal infrastructure to consolidate existing Web applications 
into a one-site gateway to the Web was not a new concept or technique. He teaches 
that by the time of his invention 'portals have become popular mechanisms that enable 
users to access information from multiple different network sites at once' (c3:37-39). 
Therefore, even the concept of a portal infrastructure itself can be thought of as "a Web 
application" existing at the time of the invention. Anuff in fact teaches an improvement 
over the existing portal architecture. Therefore, it can be said that Anuff further teaches 
a technique for adapting an existing portal Web application into a modular portal 
infrastructure to make it suitable to or fit for the current organizational need for 
streamlining the processes involved in offering a feature-rich portal while minimizing the 
complexity and cost of developing, deploying, administering and continually enhancing 
portals (c1:40-62). In other words, referring to the Portal Front Page 18 illustrated in Fig. 
2, one skilled in the art will readily realize that the resources such as "Bookmarks", 
"Search", "Company Directory", "News", and "Discussion Boards" can very well be 
based on components from an existing portal application (i.e., at least one component of 
said Web application), wherein the portal application is not modularized according to the 
technique espoused by Anuff. The existing portal application and corresponding 
components can exist physically as appropriately coded by developers or can exist in 
the form of mere conception or prior art knowledge of a skilled artisan. However, Anuff 
teaches a portal that incorporates these components as independent modules so that 
they can be readily and independently updated by the entities who provide them, 
without affecting other features of the portal (see c2:9-12). Such incorporation, no 
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matter how it is implemented, amounts to "adding at least one component of said Web 
application to a portal platform" as claimed. 

However, upon further consideration of the reference in question for the 
preparation of this Answer, the Examiner believes that Anuff in fact at least implicitly 
teaches "adding at least one component of said Web application to a portal platform" even if 
the terminology "Web application" is interpreted to mean not just a known Web 
application (i.e., in the form of a concept or knowledge) but an actual instance of a 
particular implementation of a Web application (i.e., a Web application constructed from 
a number of Web components appropriately coded by the developer that provide some 
information or application logic to the user). This is because Anuff teaches that each 
module within the portal represents a network resource that can be accessed by a user 
through the portal (see Abstract). He further mentions, "As will be apparent from the 
discussion that follows, these resources can be applications, databases, services informational 
content, e-commerce offerings, and the like, that are available from one or more of the servers 
12a-12n. Some of these resources may be provided by the employer (or other provider of the 
portal), whereas others may come from independent third parties ." Emphasis added, see 
c3:61 -c4:1 . Elsewhere he again mentions, "One of the significant advantages of the portal 
framework of the present invention is the fact that the resources that are made available to the 
user via the modules can come from a variety of third-party sources . Emphasis added, see 
c1 0:52-55. Since some of the modules on the portal platform make available to the user 
resources provided by third parties, it follows that these third party resources represent 
existing Web applications, since at least these third party resources are not built from 
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scratch by the portal provider but represents resources that are already provided by 
third parties. Therefore, by providing access to these third party Web application 
resources, which can very well exist as components of prior art portal application, via 
designing and implementing the modular portal, Anuff teaches a technique for adapting 
an existing Web application into the proposed portal infrastructure. The notion that Anuff 
teaches adding at least one component of an existing Web application to the portal 
platform is further supported by the teaching that the portal is said to be an object- 
oriented system built on an object model, illustrated in Figs. 4, 6 and 7, using objects 
built on top of existing objects. Regarding the object model built using object oriented 
paradigm, Anuff mentions, "Software objects are also extensible: other objects can be built on 
top of existing objects , allowing the new object to extend the concept of the old object without 
having to rewrite the functionality ". Emphasis added, see c4:54-57. That is, Anuff at least 
implicitly teaches that the modular portal is built using new module objects which extend 
the concept of old module objects without having to rewrite the functionality. 
Additionally, Anuff elsewhere teaches utilizing technology for allowing configuration-data 
driven resolution of service implementations within the portal server, and mentions, 
"This allows the portal provider to use existing implementations or define their own, and 
substitute their chosen implementation into the system without rewriting source code that uses 
the implementation ." Emphasis added, see c5:49-67. Therefore, Anuff clearly teaches 
reuse of existing components of a Web application in implementing his modular portal 
infrastructure. It is because Anuff incorporates components of existing Web applications 
into his portal platform for adapting an existing Web application into the proposed portal 
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infrastructure, that "an entire working portal can be up and running very quickly: in hours or 
days, rather than weeks or months that were required prior to the invention. Organizations can, at 
their own pace, change all aspects of the look-and-feel of the portal, integrate their own content, 
and use the portal server's development tools to extend out-of-the-box functionality... thereby 
promoting integration with existing systems and reducing required learning time." See d 7:27- 
37. Referring to Fig. 2 again, none of the modules 26 such as "Bookmarks", "Search", 
"Company Directory", "News", and "Discussion Boards" represent any novel 
functionality but are known functionalities in the art at the time of the invention. It would 
be unreasonable to believe that a person of ordinary skill in the art would rewrite the 
code for these modules from scratch. In the contrary, a skilled artisan would readily 
realize that one is more likely to re-use existing codes for developing at least some 
portions of these modules as part of the modular portal platform. Thus the Examiner 
concludes that Anuff teaches a technique for adapting a Web application to a portal 
application by adding at least one component of said Web application to a portal 
platform. 

Appellant further argues that Anuff fails to teach "defining at least one Web flow 
relationship representing interactions between said at least one component of said Web 
application; and converting said at least one Web flow relationship into at least one event, 
defined within said plurality of portlets, wherein said at least one event corresponds to said 
interactions." See page 16 in the Brief. Regarding this limitation of claim 6, the Final 
Office Action explained, "defining at least one Web flow relationship is inherent in the 
reference since there has to be a defined Web flow relationship in order to show the appropriate 
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page based on the user interaction at the portal. Anuff teaches implementing the defined Web 
flow relationship by converting it into user selection events such as selecting a link or button in 
order to display appropriate page based on the selection. See pages 5-6 of the Final Office 
Action. Appellant argues, "However, this appears to focus on the proposed functionality of a 
given module that is implemented within Anuff s portal framework, rather than a process for 
adapting an existing Web application into the portal (e.g., into the given module). For instance, 
while the operation of a given module within Anuff s portal may support a certain flow of 
interaction with a user by enabling the user to click on a hyperlink, etc., Anuff fails to disclose 
defining a Web flow relationship for a Web application and converting such relationship into an 
event defined in a portlet of a portal in order to adapt a Web application into such portal (e.g., in 
order to adapt a Web application into a module). Indeed, the module of Anuff may be created 
from scratch, rather than attempting to adapt an existing Web application into such modules, as 
Anuff provides no disclosure of any such adapting of an existing Web application into its portal 
framework." See page 17 in the Brief. In response the Examiner contends that since the 
modules within Anuffs portal infrastructure supports certain flow of interaction with a 
user by enabling a user to click on a hyperlink, this implies that the implementation of 
such flow of interaction necessarily requires that the Web flow relationship representing 
the interaction is defined first at the design or planning stage of development of such a 
portal platform. For further clarification, Anuff teaches the limitation "defining at least one 
Web flow relationship representing interactions between said at least one component of said 
Web application" by defining ways or a model of interactions between the user and a 
component at design stage of development, i.e., defining how a user is to interact with a 
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component in order to access its service, and teaches the limitation "converting said at 
least one Web flow relationship into at least one event, defined within said plurality of portlets, 
wherein said at least one event corresponds to said interactions" by implementing the defined 
model of interaction into user selection events such as selecting a link or button in order 
to display appropriate page based on the selection. Such teaching can be found 
illustrated as Object Models in Fig. 4, 6 and 7 for designing the portal infrastructure and 
additionally or in the alternative deemed inherent in the reference. 

For claims 7-10, Appellant has not provided any additional argument besides 
what has been already discussed above with respect to claim 6. Therefore, the same 
argument applies for these claims. 

Independent Claim 1 1 and Dependent Claims 12-18 and 20 

Regarding claim 1 1 , Appellant mentions, "Anuff fails to teach all elements of claim 
11". In particular, Appellant argues, "While Anuff proposes a modular portal infrastructure or 
framework, Anuff fails to address any technique for converting a Web application into the 
proposed portal infrastructure. Thus, Anuff fails to disclose a method for 'converting a Web 
application to a portal application' in the manner recited by claim 1 1 ." This appears to be the 
same argument that Appellant has argued for claim 1 . The terminology "converting" used 
in the claim is considered synonymous to the terminology "adapting" used in claim 1 in 
the context of the invention. Therefore, the Examiner disagrees for the same reasoning 
as explained above with respect to claim 1 . For the sake of brevity, the same argument 
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discussed with respect to claim 1 is not repeated here. However, the Examiner would 
like to point out that claim 1 1 does not even recite the limitation "existing Web 
application" which was recited in claim 1, but only recites "a Web application". Appellant 
argues, "Further, the method of claim 1 1 for so converting a Web application into a portal 
application recites, in part, 'moving Web components from said Web application into a portal 
framework corresponding to said portal application'. Anuff fails to disclose at least this step of 
the method... While Anuff discloses modules, Anuff does not disclose that adapting a web 
application to such a module includes moving Web components from said Web application into a 
portal framework (e.g., module) as recited by claim 11." See page 1 8 in the Brief. The 
Examiner disagrees. The limitation "moving Web components from said Web application into 
a portal framework corresponding to said portal application " does not necessarily require 
that the components are coded components and such coded components are physically 
ported or copied to a portal platform. The limitation "moving Web components from said 
Web application into a portal framework corresponding to said portal application " can 
reasonably be interpreted to require providing functionalities that belongs to, or 
corresponds to a known Web application from within a portal platform, even if the Web 
application is not implemented with components appropriately coded by developers, but 
exists merely in conceptual form as prior art knowledge of a skilled artisan. Anuff clearly 
teaches this. As already mentioned above in the response to the argument with respect 
to claim 1 , Anuff realizes that the use of a portal infrastructure to consolidate existing 
Web applications into a one-site gateway to the Web was not a new concept or 
technique. He teaches that by the time of his invention 'portals have become popular 
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mechanisms that enable users to access information from multiple different network 
sites at once' (c3:37-39). Therefore, even the concept of a portal infrastructure itself can 
be thought of as "a Web application" existing at the time of the invention. Anuff in fact 
teaches an improvement over the existing portal architecture. Therefore, it can be said 
that Anuff further teaches a technique for adapting an existing portal Web application 
into a modular portal infrastructure to make it suitable to or fit for the current 
organizational need for streamlining the processes involved in offering a feature-rich 
portal while minimizing the complexity and cost of developing, deploying, administering 
and continually enhancing portals (c1 :40-62). In other words, referring to the Portal 
Front Page 1 8 illustrated in Fig. 2, one skilled in the art will readily realize that the 
resources such as "Bookmarks", "Search", "Company Directory", "News", and 
"Discussion Boards" can be components from an existing portal application (i.e., Web 
components from said Web application), wherein the portal application is not modularized 
according to the technique espoused by Anuff. The existing portal application and 
corresponding components can exist physically as appropriately coded by developers or 
can exist in the form of mere conception or prior art knowledge of a skilled artisan. 
However, Anuff teaches a portal that incorporates these components as independent 
modules so that they can be readily and independently updated by the entities who 
provide them, without affecting other features of the portal (see c2:9-12). Such 
incorporation, no matter how it is implemented, amounts to "moving Web components from 
said Web application into a portal framework as claimed. 
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However, upon further consideration of the reference in question for the 
preparation of this Answer, the Examiner believes that Anuff in fact at least implicitly 
teaches "moving Web components from said Web application into a portal framework 
corresponding to said portal application" even if the terminology "Web application" is 
interpreted to mean not just a known Web application (i.e., in the form of a concept or 
knowledge) but an actual instance of a particular implementation of a Web application 
(i.e., a Web application constructed from a number of Web components appropriately 
coded by the developer that provide some information or application logic to the user), 
and "moving the Web components" is interpreted to necessarily require that the 
components are coded components and such coded components are physically ported 
or copied to a portal platform. This is because Anuff teaches that each module within 
the portal represents a network resource that can be accessed by a user through the 
portal (see Abstract). He further mentions, "As will be apparent from the discussion that 
follows, these resources can be applications, databases, services informational content, c- 
commerce offerings, and the like, that are available from one or more of the servers 12a-12n. 
Some of these resources may be provided by the employer (or other provider of the portal), 
whereas others may come from independent third parties ." Emphasis added, see c3:61-c4:1. 
Elsewhere he again mentions, "One of the significant advantages of the portal framework of 
the present invention is the fact that the resources that are made available to the user via the 
modules can come from a variety of third-party sources . Emphasis added, see d 0:52-55. 
Since some of the modules on the portal platform make available to the user resources 
provided by third parties, it follows that these third party resources represent existing 
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Web applications, since at least these third party resources are not built from scratch by 
the portal provider but represents resources that are already provided by third parties. 
Therefore, by providing access to these third party Web application resources, which 
can very well exist as components of prior art portal application, via designing and 
implementing the modular portal, Anuff teaches a technique for adapting an existing 
Web application into the proposed portal infrastructure. The notion that Anuff teaches 
moving Web components of an existing Web application to the portal platform is further 
supported by the teaching that the portal is said to be an object-oriented system built on 
an object model, illustrated in Figs. 4, 6 and 7, using objects built on top of existing 
objects. Regarding the object model built using object oriented paradigm, Anuff 
mentions, "Software objects arc also extensible: other objects can be built on top of existing 
objects , allowing the new object to extend the concept of the old object without having to rewrite 
the functionality ". Emphasis added, see c4:54-57. That is, Anuff at least implicitly 
teaches that the modular portal is built using new module objects which extend the 
concept of old module objects without having to rewrite the functionality. Additionally, 
Anuff elsewhere teaches utilizing technology for allowing configuration-data driven 
resolution of service implementations within the portal server, and mentions, "This allows 
the portal provider to use existing implementations or define their own, and substitute their 
chosen implementation into the system without rewriting source code that uses the 
implementation ." Emphasis added, see c5:49-67. Therefore, Anuff clearly teaches reuse 
of existing components of a Web application in implementing his modular portal 
infrastructure. It is because Anuff incorporates components of existing Web applications 
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into his portal platform for adapting an existing Web application into the proposed portal 
infrastructure, that "an entire working portal can be up and running very quickly: in hours or 
days, rather than weeks or months that were required prior to the invention. Organizations can, at 
their own pace, change all aspects of the look-and-feel of the portal, integrate their own content, 
and use the portal server's development tools to extend out-of-the-box functionality... thereby 
promoting integration with existing systems and reducing required learning time." See d 7:27- 
37. Referring to Fig. 2 again, none of the modules 26 such as "Bookmarks", "Search", 
"Company Directory", "News", and "Discussion Boards" represent any novel web 
service functionality but are known functionalities in the art at the time of the invention. It 
would be unreasonable to believe that a person of ordinary skill in the art would rewrite 
the code for these modules from scratch. In the contrary, a skilled artisan would readily 
realize that one is more likely to re-use existing codes for developing at least some 
portions of these modules as part of the modular portal platform. Thus the Examiner 
concludes that Anuff teaches a technique for converting a Web application into a portal 
application by moving Web components from said Web application into a portal 
framework corresponding to said portal application. 

For claims 12-18 and 20, Appellant has not provided any additional argument 
besides what has been already discussed above with respect to claim 1 1 . Therefore, 
the same argument applies for these claims. 



Dependent Claim 19 
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Dependent claim 1 9 depends from claim 1 1 . Therefore, the same argument as 
discussed with respect to claim 1 1 above also applies to this claim. Appellant further 
argues, "Anuff further fails to teach creating a new window for information retrieved in 
response to a call to a URL from a Web application". See page 1 9 in the Brief. The 
Examiner disagrees. Referring to Fig. 2, Anuff shows portlets, i.e., modules 26, with 
titles "Bookmarks", "Search", "Company Directory", "News" and "Discussion Boards". 
Each of these modules either alone or in combination has been relied upon as "said 
Web application" recited in the claim (see the discussion with respect to claim 1 1 
above). The illustration of Fig. 2 shows a "Portal Front Page" 18 (see c3:44-45). This 
"Portal Front Page" is also illustrated in the object model of Fig. 4. As shown, a module 
window corresponds to a "View" object in the object model of Fig. 4. Now referring to 
section 3.3.2 Views, Anuff teaches, "Examples of views are the front page of a portal, where 
a module is displayed within a box or other graphical region (as shown in Fig. 2);" (see c6:51 - 
54). He further mentions, "A new view object is created for each HTTP request." (see c6:57- 
58). From the above description, it is apparent that a "View" object corresponds to a 
"window" containing the module 26 of the Portal Front Page as illustrated in Fig. 2. Also, 
it is implicit in the reference that the news headlines displayed in the News module in 
Fig. 2 are URLs. Now based on the teaching that by interacting with any one of these 
modules, the user can access the information or services provided by that module, and 
by clicking on a headline in the "News" module, the user can be presented with the full 
text of the news story to which that headline pertains (see c4:1-5), it is apparent that 
Anuff teaches retrieving information in response to a call to a URL from a Web 
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application. Furthermore, since it is well known that a URL call generates an HTTP 
request (also shown as HTTP Connection in Fig. 12), and the explicit teaching "a new 
view (i.e., a window) object is created for each HTTP request" (see c6:57-58), it follows 
that Anuff teaches "creating a new window for information retrieved in response to a call to a 
URL from a Web application". 

Independent Claim 21 and Dependent Claims 22-23 and 25 

Regarding Claim 21 , Appellant mentions, "Anuff fails to teach all elements of claim 
1." However, in particular, Appellant argues, "While Anuff proposes a modular portal 
infrastructure or framework, Anuff fails to address any technique for adapting an existing Web 
application into the proposed portal infrastructure. Thus, Anuff fails to disclose a method for 
'converting a Web application to a portal application' in the manner recited by claim 11." This 
appears to be the same argument that Appellant has argued for claim 1 . Therefore, the 
Examiner disagrees for the same reasoning as explained above with respect to claim 1 . 
For the sake of brevity, the same argument discussed with respect to claim 1 is not 
repeated here. Appellant argues that Anuff fails to disclose "means for defining at least 
one Web flow relationship" and "means for converting said at least one Web flow 
relationship". It has been already discussed with respect to claim 6 above that Anuff 
teaches defining at least one Web flow relationship and converting said at least one 
Web flow relationship (see pages 19-20 above). As for the means, the Brief mentions 
computer-executable software code executing on a computer to be the means for 
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performing the above functions. Anuff also uses computer-executable software code 
executing on a computer to perform these functions and therefore anticipates the claim. 

For claims 22-23 and 25, Appellant has not provided any additional argument 
besides what has been already discussed above with respect to claim 21 . Therefore, 
the same argument applies for these claims. 

Dependent Claim 24 

Dependent claim 24 depends from claim 21 . Therefore, the same argument as 
discussed with respect to claim 21 above also applies to this claim. Appellant further 
argues, "Anuff further fails to teach modifying business logic of a Web application component 
to return output as a data-descriptive meta-language document". See page 21 in the Brief. The 
Examiner disagrees. Anuff clearly mentions, "One of the significant advantages of the portal 
framework of the present invention is the fact that the resources that are made available to the 
user via the modules can come from a variety of third-party sources. Consequently, however, the 
content for the modules may be largely unstructured, which can be problematic when it is to be 
made available for manipulation and display within the portal. To this end, therefore, a parser 
technology is employed for retrieving data from external web sites and various other sources, 
translating the data into XML, and returning structured results as objects for use by other entities, 
such as modules. " (Emphasis added, see d 0:52-62). Therefore applying a parser for 
translating the data amounts to modifying business logic of Web application 
components (i.e., third party sources) to return output as data-descriptive meta- 
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language document (i.e., XML). Since the means is said to be computer-executable 
software code executing on a computer, and the parser is clearly a computer- 
executable software code executing on a computer, Anuff anticipates the claimed 
limitation. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 
/Rashedul Hassan/ 
Examiner, Art Unit 2179 
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